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DETAILED DESCRIPTION 

2 Design Ov rview 

The Vulcan product which is designed to stream audio from a given audio content server 
PC to multiple connected audio receivers, is made up of a collection of components, i.e. 
Beads, which will communicate through command requests and event responses. This 
design will outline the structure of all commands and events in the system. In addition, 
the structure of any required protocol initialization files will also be designed. 

3 Process Summary 

The following diagram details the high level overview of all of the components of the 
Vulcan architecture and the links between those components. 

Component Architecture Overview 



Server feature 



Audio St ream' Spttrtei 



Discovery 



vfWdio . 



Control f 



■Fite 



Hear&eet 



Crawiarv 



i 



HTTP 
Server 



Local 
Disk 




Internet 






Portal 


Speaker 


Heartbeat 


P 


Audio 
Out 


Discovery 


Receiver Feature 



Audai- 
Cordroi:;!;: 
Synchronous ■ 



* T 



• : :CCor<?ertt:::' : 



Heartbeat 



Recover f 



Discover 



Browser Feature 



The interface between each component is detailed in the Component Interfaces Design 
document which is available at: Component lnterfaces.xls . 

The basic responsibility of each component in the diagram above is as follows: 
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AudioStreamSource; 

• Interface bead which receives commands from AudioSwitch and talks to audio 
source interface libraries such as Real Audio and Windows Media. 

• Sends asynchronous events to AudioSwitch. 

AudioSwitch: 

• Receives commands from AudioControl and sends commands to 
AudioStreamSource. 

• Receives events from AudioStreamSource and sends events to AudioBrowserList. 

• Controls the switching of audio from AudioStreamSource to one or more 
Receivers. 

• Requests playlist content (see: Playlist Parsers), upon receipt of a CreateActivity 
command that contains a Playlist or a SetPlaylist command. 

• Receive commands on it's config edge to list all current activities that it owns. 

AudioControl: 

• Receives commands from AudioControlSynchronous and sends commands to 
AudioSwitch. 

• Requests playlist content (see: Playlist Parsers), upon receipt of the 
ExpandPlaylist command from an Audio Browser, 

AudioControlSynchronous: 

• Receives events from AudioBrowseilisC^dioContentList and 
AudioReceiverList. , ?= ' 

• Sends commands to AudioControl on the server local to the requested content or 
on the server responsible for serving up internet content, when applicable. 

• Generates unique ActivitylDs across all Audio Browsers, using IP address and 
sequential ID. 

AudioBrowserList: 

• Receives messages from Heartbeat about the addition/removal of Audio Browsers 
and requests the initial list of active activities from AudioSwitch when a new 
Audio Browser is detected. 

• Receives events from AudioSwitch and sends events to all active Audio 
Browsers. 

AudioContentList: 

• Receives messages from Heartbeat about the addition/removal of Audio Servers. 

• Users IP address of new server to get virtual roots from HTTPServer, and uses 
virtual roots to get audio content from FileCrawler. 

• Forwards new (and removed) content events to AudioControlSynchronous. 
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AudioReceiverList: 

• Receives messages from Heartbeat about the addition/removal of Audio 
Receivers and forwards those messages in the form of events to 
AudioControlSynchronous. 

HTTPServer: 

• Receive commands on it's config edge to add/remove/modify virtual roots. 

• Receive a command on it's config edge to return contents of virtual roots table. 

FileCrawler: 

• Receive a command on it's config edge to return a list of files for a given HTTP 
virtual root (and it's subdirectories) for a given content type (i.e. extension). 

• Transform all local files names into encoded URLs. 

Playlist Parser: 

• Receive a format specific playlist and convert it into a generic filelist. 

• There will actually be one PlaylistParser for each support playlist type, (i.e. 
M3UParse, PLSParse, ASXParse, etc.). 

FileGlobalizer: 

• Transforms local file names into URLs. It will be used in conjuction with the 
Playlist Parsers to return file lists with OU.s4nstead.0f just local file names. 

Heartbeat: 

• On startup, post a message to discoyefyiannouncing the presence, or absence, of 
each Strings feature, i.elLpcaj Content Server, Internet Content Server, Receiver 
or Browser. 

• Receive messages from discovery channels for each feature and forward events 
for each existing feature. 

4 Design Concepts 

The architecture is made up features which can be distributed in any way across hosts in 
the network. The only requirement is that at most one instance of a given feature can be 
running on a host at a time. The features that make up the architecture are the Server, 
Receiver and Browser. Server features can be further broken down to support local 
content, internet content or both. Heartbeat is responsible for discovering all features and 
forwarding corresponding events appropriately. AudioBrowserList will receive events 
for Browser features, AudioContentList will receive events for Server features and 
AudioReceiverList will receive events for Receiver features. 

All features can communicate asynchronously over a well known port using sockets, or 
synchronously via an HTTP request. 

AudioControlSynchronous will receive all accessible content and receivers (from 
AudioContentList and AudioReceiverList, respectively) and all current activities from 



AudioBrowserList on startup. Subsequent events to AudioControlSynchronous will only 
contain deltas to the original data dump and will be initiated as follows: 

• An event is sent from AudioBrowserList indicating a modification of an existing 
activity. 

• An event is sent from AudioContentList indicating that a new PC came on-line 
with new playlist/audiofile info or an existing PC went off-line, thus removing 
existing playlist/audiofile info. 

• An event is sent from AudioReceiverList indicating that a new audio receiver 
came on-line or an existing audio receiver went off-line. 

When AudioContentList receives the event from Heartbeat announcing a new Server 
feature, it will request the virtual roots on that server from HTTPServer. Then, it will 
request the audio content for each virtual root, for each supported content type, from the 
FileCrawler on the newly discovered server. FileCrawler will be responsible for parsing 
each filename and replacing all local file prefixes with URLs. For example, if it finds a 
playlist with the URL: C:\My Documents\My Music\workout.m3u, it will need to change 
that to http:\\a.b.c.d\c\my documents\my music\workout.m3u, assuming the virtual root is 
set up such that c:\ maps to http:\\a.b.c.d\c. FileCrawler will get the virtual roots from the 
HTTPServer config edge. 

AudioContentList will also be responsible for sending an event to 
AudioControlSynchronous which details which serverslare serving local content and 
which are serving internet content. Thisrivill allow ?^udi6Gontrol Synchronous to request 
audio content from the correct server. 

When AudioSwitch receives a request from; AuSioControl to open a playlist, it will 
request the contents of thefplaylist, which will invoke a content specific playlist bead (i.e. 
M3UParse, PLSParse, ASXParse, etc.), to parse the results returned from HTTPClient 
and pass on the content independent results. The results from the playlist parser will be 
passed through FileGlobalizer to replace all local file names with encoded URLs. 

5 XML Format Specification 

The current assumption is that the structure of all commands and event interfaces will use 
an XML message format. However, all implementation should be done in a modular way 
such that this decision can be changed at a later date without major effect on the code. 

5.1 Element List 

This section documents all XML elements supported in the system. Each element is 
shown with it's associated attributes and all optional attributes will be in italics. If all 
attributes of a particular element are optional, it must contain at least one attribute to be 
valid. Child elements of a given element are not shown. 

<CONTENT_ EVENT version^' 1 . 0" /> 

< S ERVER_ EVENT' ver sion=" 1 . 0" / > 

<RECEIVER_EVEN7 version^" 1 . 0" /> 

<ACTIVITY_EVEN1 version^' 1 . 0" /> 
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< P LAYBACK_EVENT 
<HEARTBEAT_EVENT 

<ACT I VI T Y_COMMAN D 

< P LAYBAC K_COMMAN D 

<RESCAN_RESPONSE 

<HEARTBEAT_MESSAGE 
<FILE_EXTENSIONS 
<LIST_EXTENSIONS 
<HOSTS 

<VIRTUAL_ROOTS 
<MULTICAST_GROUPS 

<ADD_T RACKS/ > 
<REMOVE_T RACKS / > 

<ADD_PLAYLISTS/> 

< REMOVE PLAYLISTS/> 



<ADD_I NTERNET_S ERVERS / > 
<REMOVE_INTERNET_SERVERS/> 

<ADD_LOCAL_S ERVERS / > 

< REMOVE_LOCAL_S ERVERS / > 

<ADD_RECEIVERS/> 
<REMOVE_RECEIVERS/> 

<ADD_TARGETS/> 
< REMOVE TARGETS /> 



<ADD_HOST/> I 
<REMOVE_HOST/> 

<CREATE_ACTIVITY/> 
<SET_PLAYLIST/> 
<SET_MODE/> 
<RESET CONTENT/ > 



version=" 1.0" /> 
version="1.0"/> 

version=" 1.0" /> 
version*" 1.0" /> 

version* 7 '!. 0"/> 

version= // 1.0 // /> 
version*" 1.0" /> 
version*" 1. 0"/> 
version*" 1. 0"/> 
version*" 1. 0 // /> 
version*" 1 . 0"/> 



< VI RT U AL_ ROOT n ame =" vi r t u a 1 Ro o t N ame" 

localRoot*" localRootName" /> 



<HOST 
<FILE 

<IP_ADDRESS 

<MODE 

< STATUS 



ipAddress=" ipAddress" 
name*" hos tName" 
dnsName=" dnsName" /> 

uri="linkName" fullName=" localName" /> 
value*" 224 . 0. 0.xx"/> 
value*" Linear I Random" /> 
value*" Success i Failure" /> 
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<ERROR/> 



<STRINGS_CODE valued errorValue" /> 



<ACTIVITY 
< STATE 



<FILELIST/> 
<PLAYLIST/> 
<TRACK/> 
<EXTENSION 

<PROGRESS 

<LENGTH 

<POSITION 

<TITLE 

<ARTIST 

<ALBUM 

<GENRE 

<OPEN/> 

<PLAY/> 

<STOP/> 

<NEXT/> 

<PREVIOUS/> 

<SEEK 

<PAUSE/> 

<RESUME/> 

<CLOSE/> 



id="id" 



name-' name" /> 



value = 

" Idle j Connecting | Buffering | Playing 
Stopped | Closed | Error 77 /> 



value=" extension' 7 /> 

value="100" units^ 7 percentage 77 /> 
value=" 0" units=" milliseconds 77 /> 
value=" 0" units=" milliseconds 77 /> 
name^' Title 7 ' /> 
name=" Artist 77 /> 
name-' Album 7 ' /> 
name=" Genre" /> 



Paused ! 



of fsetr 77 value 7 ' 



units^rriilli seconds 7 ' /> 



5.2 Element Structure 

This section documents the structure of the supported XML elements., by outlining the 
parent-child relationships between all of the elements. Attributes of each element are not 
included in this section. 



1 Element Name 


Valid Parent Elements 


Valid Child Elements 


ACTIVITY 


ACTIVITY COMMAND, 
ACTIVITY JE VENT 


ADDTARGETS, ADD TRACKS, 
ALBUM, ARTIST, CLOSE, 
CREATE ACTIVITY, ERROR 
GENRE, LENGTH. NEXT, 
PAUSE, PLAY. PLAYLIST, 
POSITION, PREVIOUS, 
PROGRESS, 
REMOVE TARGETS, 
REMOVE TRACKS, 
RESET CONTENT. RESUME. 
SET MODE. SET PLAYLIST^ 
SEEK, STATE. STOP. TITLE. 
TRACK 


ACTIVITY COMMAND 


NONE 


ACTIVITY 
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ACTIVITY EVENT 


NONE 


ACTIVITY, ERROR 


ADD HOST 


HEARTBEAT EVENT 


HOST 


ADD INTERNET SERVERS 


SERVER EVENT 


HOST 


ADD LOCAL SERVERS 


SERVER EVENT 


HOST 


ADD PLAYLISTS 


CONTENT EVENT 


FILE 


ADD RECEIVERS 


RECEIVER EVENT 


HOST 


ADDTARGETS 


ACTIVITY, 
CREATE ACTIVITY 


HOST 


ADD_TRACKS 


ACTIVITY, 
CONTENT EVENT, 
CREATE ACTIVITY 


FILE 


ALBUM 


ACTIVITY, 
PLAYBACK EVENT 


NONE : 


ARTIST 


ACTIVITY, 
PLAYBACK EVENT 


NONE 


CLOSE 


ACTIVITY 


NONE 


CONTENTEVENT 


NONE 


ADD PLAYLISTS. 
ADD TRACKS. ERROR 
REMOVE PLAYLISTS, 
REMOVE TRACKS 


CREATE_ ACTIVITY 


ACTIVITY 


ADD TARGETS, ADD TRACKS, 
SET MODE, SET PLAYLIST. 


ERROR 


ACTIVITY, 

ACTIVITY EVENT, ; , 
CONTENT EVENT. 
PLAYBACK EVENT, 
RECEIVER EVENT 


STRINGS_CODE 


EXTENSION 


FILE EXTENSIONS, 
MST EXTENSIONS? ; 


NONE 


FEATURE AVAILABLE 


HEARTBEAT MESSAGE 


NONE 


FEATURE NOT AVAILABLE . 


HEARTBEAT MESSAGE 


NONE 


FILE 


ADD_PLAYLISTS, 
ADD TRACKS, FILELIST, 
OPEN, PLAYLIST, 
REMOVE PLAYLISTS. 
REMOVE TRACKS. 
SET PLAYLIST. TRACK 


NONE 


FILE EXTENSIONS 


NONE 


EXTENSION 


FTLELIST 


NONE 


FILE ~~J 


GENRE 


ACTIVITY, 
PLAYBACK EVENT 


NONE 


HEARTBEAT EVENT 


NONE 


ADD HOST. REMOVE HOST 


HEARTBEATMESSAGE 


NONE 


FEATURE AVAILABLE. 
FEATURE NOT AVAILABLE 


HOSTS 


NONE 


HOST 


HOST 


ADD HOST, 
ADDRECEI VERS, 
ADD_TARGETS. 
HEARTBEAT. HOSTS. 
REMOVE HOST. 
REMOVE RECEIVERS. 
REMOVE TARGETS 


NONE 


IP ADDRESS I 


MULTICAST GROUPS 


NONE 
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LENGTH 


ACTIVITY. 
PLAYBACK EVENT 


NONE 


LIST EXTENSIONS 


NONE 


EXTENSION 


MODE 


SET MODE 


NONE 


MULTICAST GROUPS 


NONE 


IP ADDRESS 


NEXT 


ACTIVITY 


NONE 


OPEN 


PLAYBACK COMMAND 


FIT F 

I ILL 


PAUSE 


ACTIVITY, 

PLAYBACK COMMAND 


NONE 


PT AY 


A PTTVTT'V 

PI AYRACK COMMAND 




PLAYBACK_COMMAND 


NONE 


OPEN, PAUSE, PLAY, RESUME. 

^FFTf STOP 


PI AYBAPK FVFNT 




AT RTTM APTTCT FRROP 

GENRE, LENGTH, POSITION, 
PROGRFSS STATF TITI F 

1 1\. VJ Xvi_j JU, Jl AIL, 1X1 1 -I f 


PLAYLIST 


ACTIVITY 


FILE 


POSITION 


ACTIVITY 

/A V_ X X V X X I , 

PLAYBACK EVENT 


xNv/xNC 


PREVIOUS 


ACTIVITY 


NONE 


PROGRESS 


ACTIVITY 

/ * Xw-* X X ▼ X X X « 

PLAYBACK EVENT 


NONE 


RECEIVER_EVENT 


NONE 


ADD RECEIVERS. ERROR, 
REMOVE RECEIVERS 


REMOVE HOST 


HEARTBEAT EVENT 


HOST 


REMOVE INTERNET SERVERS 


SERVER RESPONSE &> 


HOST 


REMOVE LOCAL SERVERS 


SERVER RESPONSE 


/HOST 


REMOVE PLAYLISTS 


CONTENT EVENT 


FILE 


REMOVE RECEIVERS 


RECEIVER;? EVENT 


HOST 


REMOVE TARGETS 


ACTIVITY ; 


HOST 

X 1V/U X 


REMOVE_TRACKS 


, ACTIVITY, 


FILE 




CONTENT EVENT 




RESCAN RESPONSE 


NONE 


STATUS 


RESET CONTENT 


ACTIVITY 


NONE 


RESUME 


ACTIVITY, 


NONE 


SEEK 


ACTIVITY, 

PT AYRAPkT POMMAMTI 


NONE 


SERVERRESPONSE 


NONE 


ADDINTERNETSERVERS, 

A FiH T OP AT QFDVFDC 

REMO VEINTERNETSER VERS , 

RFMOVF T HPAT ^FRVFT?Q 


SET MODE 


ACTIVITY 
CREATE ACTIVITY 


MODF 


SET_PLAYLIST 


ACTIVITY 
CREATE ACTIVITY 


FTI F 


STATE 


ACTIVITY. 
PLAYBACK EVENT 


NONE 


STATUS 


RESCAN RESPONSE 


NONE 


STOP 


ACTIVITY. 

PLAYBACK COMMAND 


NONE 


STRINGS CODE 


ERROR 


NONE 


TITLE 


ACTIVITY. 


NONE 
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// 





PLAYBACK EVENT 




TRACK 


ACTIVITY 


FILE 


VIRTUAL ROOT 


VIRTUAL ROOTS 


NONE 


VIRTUAL ROOTS 


NONE 


VIRTUAL ROOT 



6 Protocol Interface Specification 

This section describes all protocol interfaces which utilize XML and query string 
message format. This includes all command, event and config edges as well as interfaces 
to discovery and initialization file formats. 



6.1 AudioControlSynchronous 

AudioControlSynchronous supports an Event Interface on which it receives events from 
AudioBrowserList, AudioContentList and AudioReceiverList to drive the GUI and a 
config interface on which it receives commands from a web browser, however, the config 
interface is not included in this document. It also outputs commands to the AudioControl 
Command Interface and Config Interface . 

6.1 .1 Event Interface 

This interface supports four separate events: content, server, receiver and activity events. 
Event event is described in detail below. 

The first type of event is a content event which contmns changes to the available content 
based on the availability of server features on the network. AudioControlSynchronous 
can support any combination^ elements under the content_event root element. 
AudioControl Synchronous ! will also needito be rabust enough to support duplicate add 
and remove events, by ignoring all but thie first event. The structure of a content event is 
as follows: 

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
<CONTENT_EVENT version^" 1 . 0" > 
<ERROR> 

<STRINGS_CODE value=" errorValue" /> 

</ERROR> 

<ADD_TRACKS> 

<FILE uri="linkName" ful lName=" 1 oca lName" /> 

<FILE uri="linkName" f ull Name^" local Name" /> . 
</ADD_TRACKS> 

<ADD__PLAYLISTS> 

<FILE ur I ="linkName" 

< FI LE url =" 1 in kN ame" 
</ADD_PLAYLISTS> 

<REMOVE_T RACKS > 

<FILE urJ^'linkName" fullName=" localName" /> 
<FILE url=" iinkName" f ullName=" 1 ocalName" /> 
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fullName=" localName" /> 
fullName=" localName" /> 



< / REMOVE_T RACKS > 

< REMOVE_PLAYLI STS > 

<FILE uri=" linkName" f ullName=" localName" /> 
<FILE url=" linkName" fullName^' local Name" /> 

< / REMO VE_ P LAY L I S T S > 

< / C ONT ENT_E VENT > 

The second type of event is a server event which contains changes to the available servers 
based on the availability of server features on the network, and whether a server supports 
local content, internet content or both. AudioControlSynchronous can support any 
combination of elements under the server_event root element. 
AudioControlSynchronous will also need to be robust enough to support duplicate add 
and remove events, by ignoring all but the first event. The structure of a server event is 
as follows: 

<?xml version= f, 1.0" encoding="UTF-8" standalone= M yes" ?> 
<SERVER_EVENT version=" 1 . 0" > 
<ERROR> 

<STRINGS_CODE value=" errorValue" /> I 

</ERROR> 

<ADD_INTERNET_SERVERS> 

<HOST ipAddr e s s =" i p Address" 

name^hostName" i 

dn s^ajne^-dris Name" / > ;,. 
</ADD_INTERNET_SERVERS> 4 

<ADD_LOCAL_S ERVERS>%: ; ' r ' 

<HOST ipAddres s=" ipAddr ess" 
. najne=" hos tName" 
dnsName-' dnsName" /> 
</ADD_LOCAL_SERVERS> 

<REMOVE_INTERNET_SERVERS> 

<HOST ipAddress="ipAddress" 

name=" hos tName" 

dnsName=" dnsName" /> 
</REMOVE_INTERNET_SERVERS> 

. <REMOVE_LOCAL_SERVERS> 

<HOST ipAddress="ipAddress" 
name=" hos tName" 
dnsName=" dnsName" /> 
</REMOVE_LOCAL_SERVERS> 

</SERVER_EVENT> 

The third type of event is a receiver event which contains changes to the available 
receivers based on the availability of receiver features on the network. 
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AudioControlSynchronous can support any combination of elements under the 
receiver_event root element. AudioControlSynchronous will also need to be robust 
enough to support duplicate add and remove events, by ignoring all but the first event. 
The structure of a receiver event is as follows: 

<?xml version="1.0" encoding="UTF-8" standalone= M yes" ?> 

< RECEIVER EVENT version=" 1 . 0" > 

— j 

<ERROR> 

<STRINGS_CODE value=" errorValue" /> 

</ERROR> 

<ADD_RECEIVERS> 

<HOST ipAddress="ipAddress" 
. najne="hostName" 

dnsName=?' dnsName" / > 
</ADD_RECEIVERS> 

<REMOVE_RECEIVERS> 

<HOST ipAddress="ipAddress" 
name=" hos tName" 

dnsName=" dnsName" /> . . 

</REMOVE_RECEIVERS> 

</RECEIVER_EVENT> 

The fourth type of event is an activity event which contains changes to the active 
activities in the system. Airactivity event can contain multiple activity elements and 
an activity element can contain any combination of child elements. The structure of an 
activity event is as follows: 
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<ACTIVITY_EVENT version=" 1 . 0" > 
<ERROR> 

<STRINGS_CODE value=" errorValue" /> 

</ERROR> 

<ACTIVITY id="id" name=" name" > 
<ERROR> 

<STRINGS _CODE value*" errorValue" /> 

</ERROR> 

< AD D_TARG ET S > 

<HOST ipAddress="ipAddress" 
name=" hostName" 
dnsName=" dnsName" /> 

< / AD D_TARG ET S > 

<REMOVE_TARGETS> 

<HOST ipAddress=" ipAddress" 
name=" hostName" 
d/is7Va7ne="dnsName" /> 
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</REMOVE TARGET S> 



<PLAYLIST> 

<FILE url=" linkName" 
</PLAYLIST> 

<TRACK> 

<FILE urI= /, linkName /, 
</TRACK> 



fullName^' localName" /> 



fuIiiVajne=="localName" /> 



value = 

"Idle | Connecting I Buffering I Playing . | 
Paused | Stopped I Closed I Error" /> 

valued 100" units=" percentage" /> 

value=" 0" units^' milliseconds" /> 

value=" 0" units=" milliseconds" /> 

name=" Title" /> 

name- 7 Artist" /> 

name=" Album" /> 

name=" Genre" /> 



<STATE 

<PROGRESS 
<LENGTH. 
<POSITION 
<TITLE 
<ARTIST 
<ALBUM 
< GENRE 
<CLOSE/> 
</ACTIVITY> 
</ACTIVITY_EVENT> 

Note that AudioControISynchronous will also receive content events, server events, 
receiver events and activity events on startup to set the initial state of the system. 

6,2 AudioControl 

AudioControl supports a Command Interface on which it receives commands from 
AudioControISynchronous and a Config Interface that supports synchronous requests 
from AudioControISynchronous. It also outputs commands to the AudioSwitch 
Command Interface . 

6.2.1 Command Interface 

The AudioControl command interface supports activity commands. Activity commands 
act on a specific activity and can contain at most one activity element, but an activity 
element can contain any combination of child elements. All activity commands require 
an Activityld. The Activityld is generated by AudioControISynchronous and will be a 
combination of the EP address where the browser feature is runnine and a unique 
sequentional identifier, i.e. 10.1.1.20.1, 10.1.1.20.2, etc. Once the^unique Activityld is 
generated, AudioControISynchronous can send multiple commands per activity as 
required. The complete structure is as follows: 
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<?xml version="1.0" encoding="UTF-8" standalone= n yes " ?> 



<ACTIVITY_COMMAND version=" 1 . 0" > 

<ACTIVITY id="id" name=" name" > 

< C REAT E_ACT I VI T Y > 
<ADD_TARGETS> 

<HOST ipAddress="ipAddress 
name=" hos tName" 
dnsName=" dnsName" /> 
<HOST ipAddress=" ipAddress 
name=" hos tName" 
dnsName^' dnsName" /> 
</ADDJTARGETS> 
<SET_PLAYLIST> 

<FILE url=" linkName" 
</SET_PLAYLIST> 
<ADDJTRACKS> 

<FILE url=" linkName" 
<FILE url=" linkName" 
<FILE url=" linkName" 
</ADD_TRACKS> 
<SET MODE> 



fullName^' localName" /> 



f~ulli\teme==" localName" /> 
-full^a/ne^" localName" /> 
fullName=" localName" /> 



<MODE valued Linear | Random" /> 
</SET_MODE> 
</CREATE_ACTIVITY> 

.£* 1' : -' :' : :- : i '■' ,•> 

<PLAY/> M 



<ADDJT RACKS >^ 

<FILE urlk' linkName" 
<FILE • url=" linkName" 

</ADD_TRACKS> 

< REMO VE_T RAC K S > 

<FILE url=" linkName" 
<FILE url=" linkName" 

< / REMOVE_T RAC K S > 

<SET_PLAYLIST> 

■ <FILE url=" linkName" 
</.SET_PLAYLIST> 

<SET_MODE valued Linear I 

< RE S ET_C ON T EN T / > 
<STOP/> 
<NEXT/> 
<PREVIOUS/> 

<SEEK of f set=" value" 



fullName=" localName" /> 
fullName=" localName" /> 



fullName^.' localName" /> 
fullName=" localName" /> 



fullName=" localName" /> 
Random" /> 



units=" milliseconds" /> 



<PAUSE/> 

<RESUME/> 

<ADD_TARGETS> 

<HOST ipAddress="ipAddress" 
name=" hos tName" 
dnsName=" dnsName" / > 

</ADD_TARGETS> 

< REMO VE_TARGET S > 

<HOST ipAddress="ipAddress" 
name=" hos tName" 
dnsName=" dnsName" / > 

< / REMOVE_TARGETS > 

<CLOSE/> 
</ACTIVITY> 
< /ACTIVITY COMMAND> 



The create activity command described above has very specific semantics as follows: 



| # of Playlists 


# of Tracks 


Mode 


Description 


u 


0 


Ignored 


.INVALID ' : 


0. 


1 


, . Ignored; ; : 


iiPlay single track only. 


. 1 


■ 1 , :: - ;: 


Linear* ; , : 


Play list starting at 
selected track. 


1 

* 


k _ ;;• :.: f. v. •• 


^Linear* 


Play list starting at first 
track, continue 
sequentially until end. 


1 


• 0 


Random 


Play list starting at 
random track, continue 
randomly until all songs 
played. 


0 


2+ . 


Linear* 


Play all tracks in order 
received. 


0 

1 


2 + 

2 + 


Random 


Play all tracks in random 
order. 


* Default 




Ignored 


INVALID 



6.2.2 Config Interface 

There is one command supported by the AudioControl config interface, called 
ExpandPlaylist and the syntax is as follows: 

http://i P Address/portal/protocols/AudioControl?Command= 



ExpandPlaylis 



t&Url=playlistUrl 



ExpandPlaylist returns the contents of the requested playlist with all local file names 
translated into encoded URLs. The structure of the return message is as follows: 



II 
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<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 



<FILELIST version="1.0"> 

<FILE url="linkName" r"ul2Wame="localName" /> 

<FILE url="linkName" x"u22Wame="localName" /> 

<FILE url="linkName" f"ul2Wame="localName"/> 

<FILE url="linkName" fuI2Wajne="localNarae" /> 
</FILELIST> 

6.3 AudioSwitch 

AudioSwitch supports a Command Interface on which it receives commands from 
AudioControl, an Event Interface on which it receives events from AudioStreamSource 
and a Config Interface on which it receives synchronous command requests from 
AudioBrowserList. It also outputs commands to the AudioStreamSource Command 
Interface and activity events to the AudioBrowserList Event Interface 

6.3.1 Command Interface 

AudioSwitch supports the same command interface as AudioControl, since AudioControl 
is just responsible for sending commands to the correct session of AudioSwitch. For the 
complete interface specification, see AudioControl Command Interfere 

6.3.2 Event Interface 

The data sent to AudioSwitch from AudioStreamSource via the AudioSwitch event 
interface captures changes in the current status of the AudioStreamSource session. 
AudioStreamSource will be sending events arid audio data to AudioSwitch via the event 
edge, so all payload data, include: the XML event messages will have an RTP header on 
them to differentiate the audio from the events. AudioSwitch can support any 
combination of elements under the playback_event root element. The complete 
interface is as follows: 

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> 
<PLAYBACK_EVENT version=" 1 . 0" > 

<ERROR> 

<STRINGS_CODE value=" errorValue" /> 
</ERROR> 

< STATE value = " Buffering | Playing | Paused | Stopped I 

Closed | Error"/ > 

<PROGRESS value="100" units="percentage" /> 

<LENGTH value="0" units=" milliseconds" /> 

<TITLE name="Title"/> 

<ARTIST name="Artist"/> 

<ALBUM name=" Album" /> 
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1% 



< GENRE name^' Genre" /> 



</ PLAYBACK_EVENT> 

6.3.3 Config Interface 

There is one command supported by the AudioSwitch config interface, called 

List Activities, which returns all of the currently active activities owned by AudioSwitch, 

and the syntax is as follows: 

http: / / ipAddress/portal/protocols/AudioSwitch?CoiTUTiand=ListActivities 

The structure of the return message is the same as the activity event as defined by the 
AudioBrowserList Event Interface . 

6.4 AudioStreamSource 

AudioStreamSource supports a Command Interface on which it receives commands from 
AudioSwitch. It also outputs events to the AudioSwitch Event Interface . 

6.4.1 Command Interface 

AudioStreamSource receives commands from AudioSwitch which manage the 
AudioStreamSource session and the audio being streamed by that session. 
AudioStreamSource can support any combination of elements under the 
playback_command root element. The complete structure is as follows: 

<?xml version="l. 0" encoding= 1, UTF-8 , V standalone= ,, yes" ?> 
<PLAYBACK_COMMAND version^ 7 ' 1 ,/0" > / 

<OPEN> / 

<FILE uri^inkName" fullName=" local Name ,/ /> 
</OPEN> 

<PLAY/> 

<STOP/> 

<SEEK of fset=" value" units=" milliseconds" /> 

<PAUSE/> 

< RESUME/ ></ PLAYBACK_COMMAND> 

6.4.2 Config Interface 

There is one command supported by the AudioStreamSource config interface, called 
ListMetadata, which returns all available information about a URL, and the syntax is as 
follows: 

http: / / ipaddr es£/portal/protocols/AudioStream Source?Command=ListMpt^ 
dataUJrl=ur] " " " " 
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The structure of the return message is the same as the playback event as defined by the 
AudioSwitch Event Interface . . 

6.5 FileCrawler 

FileCrawler supports a Config Interface on which it receives synchronous commands 
from AudioContentList. 

6.5.1 Config Interface 

There is one command supported by the FileCrawler config interface, called ListFiles, 
which returns all of the files under the virtual root directory that match the given 
extension. 

http: / / ipAddress/portal/protocols/FileCrawler?Command=ListFiles&Root 
=virtualRoot&Extension=extension 

The structure of the return message is as follows: 

<?xml version="l. 0" encoding="UTF-8" standalone="yes" ?> 

<FILELIST version=" 1 . 0"> 

<FILE url="linkName" 

<FILE url="linkName" 

<FILE url="linkName" 
</FILELIST> 

6.6 AudioBrowserList 

AudioBrowserList supports art Event intdrfade ^n Which it receives events from 
AudioSwitch with current activity. information and it outputs activity events as specified 
b y the AudioControlSyncli rondus Event Interface . It also supports a Heartbeat Interface 
on which it receives eventslrom Heartbeat announcing the addition or removal of new 
browser features to and from the network. 

6.6.1 Event Interface 

AudioBrowserList supports the same event interface as AudioControlSynchronous since 
AudioBrowserList is just responsible for multiplexing the events it receives to all 
connected browser features. For the complete interface specification, see 
AudioControlSynchronous Event Interface . 

6.6.2 Heartbeat Interface 

This interface receives a heartbeat event from Heartbeat announcing the the addition or 
removal of a host which is currently running the browser feature. The structure of a 
heartbeat event is as follows: 

< H EART B EAT_ EVEN T version^" 1 . 0" > 

<ADD_HOST> 

<HOST ipAddress=" ipAddress" 
^sme^'hostName" 



fullName=" localName" /> 
fullName=" localName" f> 
fullName=" localName" /> 
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dnsName=" dnsName" / > 

</ADD HOST> 



<REM0VE_H0ST> 

<HOST ipAddress="ipAddress" 
name-' ho s t Name" 
dnsName=" dnsName" /> 

</REM0VE_H0STS> 

< /HEARTBEAT EVENT > 



AudioContentList supports a Config Interface on which it receives synchronous 
commands and it outputs content events and server events as specified by the 
AudioControlSvnchro nous Event Interface . It also supports a Heartbeat Interface on 
which it receives events from Heartbeat announcing the addition or removal of new 
server features to and from the network. Lastly, it requires an initialization file to define 
the supported file and playlist types. 

6.7.1 Config Interface 

At a high level the AudioContentList config interface needs to support the ability to list 
all of the content currently accessible across the network. In addition, it needs to provide 
an interface to allow the user to rescan content that may have changed. This can be done 
globally, for a particular host or for a pairticular virtual root on a host. 

The first command supported by the config; interface is called List Content, which returns 
all of the content currently^avaUable across all discovered server features. 

http://ipAddress/pb#tal/protocols/AudioContentList?Coinmand=ListConte 



The structure of the return message is as follows: 

<?xml version="l. 0" encoding="UTF-8" standalone="yes " ?> 
<CONTENT_EVENT version^" 1 . 0" > 
<ADD TRACKS> 



6.7 



AudioContentList 



nt 



<FILE 
<FILE 
</ADD TRACKS> 



uri=" linkName' 
url=" linkName' 



fullName=" localName" /> 
fullName=" localName" /> 



<ADD_PLAYLISTS> 

<FILE 

<FILE 
</ ADD PLAYLISTS> 



urJ=" linkName" 
uri=" linkName" 



f ullName=" localName" /> 
-fullTVa/ne^'localName" /> 



</ CONTENT EVENT> 



The commands supported to rescan content are as follows: 



1A 
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http://ipAddress/portal/protocols/AudioContentList?Command=ListHosts 



http://ipAddress/portal/protocols/AudioContentList?Command=ListVirtu 
alRoots&Host=ipAddress ~ ' . . . 

http://i P Address/portal/protocols/AudioContentList?Command=Rescan 

http://ipAdd ress/portal/protocols/AudioContentList?Command=Rescan&Ho 
st=ipAddress . _ 

http : / /ipAdd ress/portal/protocols/AudioContentLis t?Cpmmand=Rescan&Ho 
st=ipAddress&VirtualRoot=virtualRoot 

The first command will return all hosts currently accessible in the system. The structure 
of the return message is as follows: 

<?xml version="1.0" encoding="UTF-8" standalone="yes " ?> 
<HOSTS versions" 1.0* > 

<HOST ipAddress="ipAddress" 
name-' hos tName" 
dn sName-' dn s N ame 77 / > 

<HOST ipAddress="ipAddress 77 
n ame-' hostN ame" 
dnsName=" dnsName // /> : 

</HOSTS> ' ; 

The second command willlreturn^ll virtual roots for a given host. The structure of the 
return message is as follows: 

<?xml version="l . 0 M encoding="UTF-8 " standalone="yes " ?> 
<VIRTUAL_ROOTS version^ 7 ' 1 . 0" > 

<VIRTUAL_ROOT name^ virtual RootName 77 

localRoot= /, localRootName // /> 
<VIRTUAL_ROOT name^ virtual RootName" 

localRoot=" local RootName' 7 /> 
<VIRTUAL_ROOT name=" virtual RootName 77 

localRoot=" localRootName 77 /> 

</VIRTUAL_ROOTS> 

The remaining three commands will scan all hosts, a particular host or a particular virtual 
root, respectively and will result in a content event being sent as defined by the 
AudioContr ol Synchronous Event Interface The config edge will return a status message 
as follows: 

<?xm] version="3 . 0" encoding="UTF- 8 " s tandalone="yes " ?> 
<RESCAN_RESPONSE ver sion=" 1 . 0" > 
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<STATUS valued Success | Failure" /> 



</ RES CAN_RES PONS E> 

6.7.2 Heartbeat Interface 

This interface receives a heartbeat event from Heartbeat announcing the the addition or 
removal of a host which is currently running the server feature. The structure of a 
heartbeat event is the same as defined by the AudioBrowserList Heartbeat Interface . 

6.7.3 Initialization File 

The AudioContentList.protocol initialization file, will contain data in XML format which 
describes what the supported audio content types are and which types are lists and which 
are single files. The XML format and will look like the following: 

<?xml version= , 1.0 l encoding= 'UTF-8 • standalone= 1 yes • ?> 

<PROTOCOL name= , AudioContentList f > 

<INITFILE module= , AudioContentList ■> 

<FILE_EXTENSIONS version=" 1 . 0" > 

< EXTENSION value="mp3"/> 
< EXTENSION value="wav"/> 
<EXTENSION valued wma"/> ? 

< / FI LE_EXTENS I ONS> , '" 

<LIST_EXTENSI ONSj versa 6n=" 1 . 0" > 

< EXTENSION value="m3u"/> 
<EXTENSION value="pls"/> 
<EXTENSION value= // asx , 7> 

< / L I S T_EXT EN S I ON S > 

</INITFILE> 

</PROTOCOL> 

Note that this is just an example and does not represent a complete list. 

6.8 AudioReceiverList 

AudioReceiverList supports a Config Interface on which it receives synchronous 
commands and it outputs receiver events as specified by the AudioControlSvnchronous 
Event Interface. It also supports a Heartbeat Interface on which it receives events from 
Heartbeat announcing the addition or removal of new receiver features to and from the 
network. 
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6.8.1 Config Interface 

There is one command supported by the AudioReceiverList config interface, called 
ListReceivers, which returns all of the discovered receivers. 

http://ipAdd ress/portal/protocols/AudioReceiverList?Comm and=ListRece 
ivers ' ~ 

The structure of the return message is as follows: 

<?xml version="1.0" encoding="UTF-8" standalone= ,, yes" ?> 

<RECEIVER_EVENT version^" 1 . 0" > 

• <ADD_RECEIVERS> 

<HOST - ipAddress="ipAddress" 
name=" hos tName" 
dn sName=" dnsName" /> 

<HOST ipAddress="ipAddress" 
/iajne=" hos tName" 
dn sName=?' dn s N ame" / > 

<HOST ipAddress="ipAddress" 
name=" hos tName" 
dnsName=" dnsName" /> 

</ADD_RECEIVERS> 

< / REC E I VER_EVENT > : | 

6.8.2 Heartbeat Interface 

This interface receives a heartbeat event from Heartbeat announcing the the addition or 
removal of a host which is currently running the receiver feature. The structure of a 
heartbeat _event is the same as defined by the AudioBrowserList H earth^t Intgrfasg 

6.9 HTTPServer 

HTTPServer supports a Config Interface on which it receives synchronous commands 
from AudioContentList. It requires an initialization file to define the supported virtual 
roots. 

6.9.1 Config Interface 

At a high level the HTTPServer config interface needs to support the ability to list the 
contents of the current virtual roots as well as the ability to modify the current virtual 
roots. This will translate to a number of supported commands as follows: 

http://ipAddress /portal/protocols/https?Conimand=ListVirtualRoots 

http://ipAddress/portal/prot ocols/https?Coin ma nd=AddVi rtu a lRoot&N a TT 1P = 
virtual Root &LocalRoot=localRoot ' 
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http://i pAddress/portal/protocols/https?Coinmand=RenioveVirtualRoot&Na 
me=virtualRoot&LocalRoot=localRoot 



The structure of the return message is the same for all commands, as all commands will 
return the current contents of the virtual roots table after the command is executed. The 
structure is as follows: 

<?xml version= M 1.0" encoding="UTF-8" standalone="yes" ?> 
<VIRTUAL_ROOTS version=" 1 . 0" > 

<VIRTUAL_ROOT name=" virtual RootName" 

localRoot=" localRootName" /> 
<VIRTUAL_ROOT name=" virtualRootName" 

localRoot=" localRootName" /> 
<VIRTUAL_ROOT name=" virtual RootName" 

localRoot=" localRootName" /> 

< / VI RTUAL_ROOT S > 

Since the virtual roots are persistent, the AddVirtualRoot and Remove VirtualRoot 
commands will need to modify the contents of the initialization file. 

6.9.2 Initialization File 

The HTTPServer. protocol initialization file, will contain the^ame XML format that is 
returned from the config edge and will look like the following: 

<?xml version= » 1 . 0 1 jncoding-?! : standal^oiie= ' yes ' ?> . 

< PROTOCOL name= ■ HTTPServer ' > ; 

<INITFILE module = ^HTTPServer 1 > 

<VIRTUAL_ROOTS version=" 1 . 0" > 

<VIRTUAL_ROOT name=" virtual RootName" 

localRoot=" localRootName" /> 
<VIRTUAL_R00T name=" virtual Root Name'' 

localRoot=" localRootName" /> 
<VIRTUAL_ROOT name^ virtual RootName' 7 

localRoot= // localRootName // /> 

< / VI RTUAL_ROOTS > 
</INlTFILE> 
</ PROTOCOL^ 

6.10 PortalSock 

PortalSock supports a Config Interface on which it receives synchronous commands from 
AudioSwitch to add or remove the given host to or from a multicast group. 
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6.10.1 Config Interface 

The PortalSock config interface needs to support the ability to add the host it is running 
on to a given multicast group, the ability to remove the host from the multicast group and 
to report which multicast groups the host is currently a part of This will translate to the 
following supported commands: 

http: // ipAddress /portal/protocols/ PortalSock?command=JoinMulticas t Group 
&IpAddress=224 . 0. Q.XX ~ " 

http://ipAddress/portal/protocols/PortalSock?coinmand=LeaveMulti castGrou 
p&IpAddress=224. 0.0. XX — : " 

http://ipAddress/portal/protocols/PortalSock?coininand=ListMulticastGroup 

All three commands should return a current list of the multicast groups that the host is 
currently part of after the command completes, as follows: 

<?xml version="l. 0" encoding= M UTF-8" standalone="yes" ?> 

<MULTICAST_GROUPS version^' 1 . 0" > 

<IP_ADDRESS value=" 224. 0.O.xx"/> 

<IP_ADDRESS value=" 224. 0.0. xx" /> 
</MULTICAST_GROUPS> 

6.11 Playlist Parsers 

All Playlist Parsers (i.e. M3Uparse, ASXParse, PLSParse, etc.) will take in the contents 
of the content specific pianist file, via an HTTP^equest on their data edge, and output an 
XML message with the fbliowingifbrmat: 

<?xml version="l. 0" encoding="UTF-8 n standalone="yes" ?> 

<FILELIST version^' 1.0" > 

<FILE fullName= // localName' , /> 

<FILE fullName=="localName"/> 

<FILE fullName="localName"/> 
</FILELIST> 

Note that the Playlist Parsers are only responsible for filling in the local file names. 

6.12 FileGlobalizer 

The FileGlobalizer will take in XML data using the filelist element, as output by the 
Playlist Parsers and is responsible for adding the url attribute, by using the 
virtual_roots available via HTTPServer's config edge. All urls added by 
FileGlobalizer should be encoded for correct transport. The output message of the 
FileGlobalizer data edge is as follows: 

<?xml ver£ion="1.0" encoding= M UTF-8 " £ tandalone= n yes " ?> 
<FILELI ST version-" 1 . 0" > 
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f ullName=" localName" /> 
fullName=" localName" /> 
f ullName=" localName 7 ' /> 

6.13 Heartbeat 

The Heartbeat protocol will run on all hosts and broadcast a message to discovery on 
startup announcing the availability of the host. The feature that the host is announcing, 
will be determined by the channel that the Heartbeat broadcasts over. The contents of the 
message will indicate whether the feature is available on the given host. Which features 
are available will be specified in the Heartbeat initialization file. The format of the 
message sent to discovery on startup is as follows: 

<?xml version= M l . 0" encoding= M UTF-8" standalone="yes" ?> 
<HEARTBEAT_MES SAGE version=" 1 . 0" > 

< FEATURE_AVAI LABLE/ > 

< FEATURE_NOT_AVAI LABLE/ > 
< /HEART BEAT_MES SAGE> 

The message must contain either the feature jwailable tag or the 

FEATURE_NOT_AVAI LABLE tag, but not both. 

The format of the Heartbeat initialization file is as follows: 

<?xml version= l 1. 0;f enpo.ding= r Uf F-8 1 standalone^ 1 yes 1 ?> 
<PROTOCOL name= , Heirtbeat »> 

<INITFILE module= , Heartbeat f > 

<NAME VALUE PAIR name= 1 Channel 1 value= 1 # 1 /> 
</INITFILE> 
</PROTOCOL> 

The supported channels are as follows: 

Channel 3 Local Server 

Channel 4 Internet Server 

Channel 5 Receiver 

Channel 6 Browser 

The Heartbeat initialization file can contain multiple channels if the host is supporting 
multiple features, such as Local Server and Internet Server 

7 



<FILE url="urlName' 
<FILE url="urlName' 
<FILE url="urlName' 
</FILELIST> 
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Au^foContentUst Event Interface: 



UstvlrtualRoots 

Rescan 
Rescan 
Rescan 



N/A 

Host 

N/A 

Host 

Host 

VirtualRoot 



Return message with aH of the content 
currently available across all discovered 
host PCs. 

Return message will all hosts server 
hosts currently available. 
Return message with all virtual roots 
accessible on the given host. 
Rescan all hosts fa new content. 
Rescan host for new content. 

Rescan host specific virtual root for new 
content. 



Add Hosts 
RemoveHosts 

AuolmeceivefUsi Conflg f rtle 


Host [, Host, Host, ...] 
Host I, Host, Host, ...] 


Send SERVER_EVENT and 
CONTENT_EVENTto 
Audk>C^)ntrolsync^ronous for new 
servers. 

Send SERVER EVENT and 
CONTENT_EVENT to 
AudioContrdSynchronous for removed 
servers. 


ListRsceivers 


N/A 


Return message with all of the 
discovered receivers. 




AddHosts 
RemoveHosts 


Host I, Host, Host, ...] 
Host [, Host, Host, ...] 


Send RECEIVER_EVENT to 
AudioControlSynchronous for new 
receivers. 

Send RECEIVER_EVENT to 
AudioControlSynchrohous for removed 
receivers. 




UstFHes 


Root 

Extension 


Return message with all of the files 
under the virtual root directory that 
match the given extension. 



These images represent screen shots from an early version of BeComm's Audio 
Browser. The Audio Browser allows someone to control multiple audio devices and 
access all of the audio data on those devices. 

This first image shows the layout of the Audio Browser. A song titled "song3" is 
currently playing on the "Living Room Stereo". The Audio Browser should follow along 
a playlist by highlighting the currently playing song. 

Bed Room Stereo is currently not in use and can be added simply by clicking on 
it. This will cause music to start playing in the Bed Room that was already playing in the 
Living Room. Removing an Audio player is also simply done by mouse click. 

A new song or playlist could be switched to at any point by double clicking on 

one. 
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playlist3 



Play 



Pausef 



Stop 



Back 



songl 
song2 
song3 
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mm 



Shuffle 



Activity 

Song: sowj3 
Artist: Some Dtuie 
Album: Some Dude Live 
Genre: Alternative 



Status: Playing 



Different audio can play on different adapters at the same time. This is done by 
clicking on the + sign on the far right of the button panel. Now a new audio session is 
created. To start playing music the user picks a song, selects any set of the available 
adapters (currently light gray represents adapters in use), and hits the play button. 
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This screen shows the Audio Browsers state before the play button is pressed. 
When it is song2 will start playing in the Bed Room. 
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AudioStream Source Events 

This document is presented to clearly specify the events generated by 
AudioStreamSource (ASS). Where the Component Communication document is 
flexible, this document is slightly more rigid specification to be used for implementation 
of the ASS events, specifying likely order (comparision of Real and WMA needs to be 
done) and exact message contents. Note that buffering can take place at any time, except 
while stopped with no outstanding commands. 

For a standard open-play scenario of an mp3 format file, following are the events 
generated by the AudioStreamSource protocol, in order: 

[Open command issued ] 

<? xml version="l, 0" encoding^'UTF-S" standalone="yes" ?> 
<PLAYBACK EVENT version^" 1.0" > 

<LENGTH valued 0" units=" milliseconds" /> 

</ PLAYBACK EVENT > 

Not implemented yet : 

<?xml ver si on="1.0" encoding="UTF-8 "_s tajidalone=^yes " _?> 
< PLAYBACK EVENT' "version^ l" 0" > ~ 



<TITLE 


name=" Title" 


/> 


<ARTIST 


name=" Artist 


"/> 


< ALBUM 


name=" Album" 


/> 


<GENRE 


name-'Genre" 


/> 



</ PLAYBACK EVENT> 

<?xml version="l . 0" encoding="UTF-8" standalone=" yes " ?> 
< PLAYBACK EVENT ve r s i on=" 1 . 0" > 

< S TATE valu e = "Stopped" / > 

</ PLAYBACK EVENT> **" 



[Play command issued ] 

<?xml version="1.0" encoding="UTF-8 " standalone="yes •" ?> 

< PLAYBACK EV ENT, versi on=" 1 . 0" > 

<STATE va Yu e" "' ""pFa yincf" / > 
</ PLAYBACK EVENT> 

Net congestion: 

<?xml version="l. 0" encoding= ,, UTF-8 ,, standalorie="yes" ?> 
< p LA YBAC K "'"EVENT vers Ton'^ 7 Y To" > "" 
< S T AT E v a 1 u e = " B u f fe r i n g 77 / > 

<PROGRESS valued 0-Y'00 ;; uni t s=" pe rcentage"/> 
</ PLAYBACK EVENT > 

[song plays to completion] 

<?xml version^"! . 0 M en coding = "UTF- 8" stan da 1 one="ye s " ? > 
< PLAYBACK EVEN?' version^ 1 . 0" > ~ 

<STATE value = " Stopped" /> 

</ PLAYBACK EVENT> 



For a standard seek scenario of an mp3 format file, following are the events generated by 
the AudioStreamSource protocol, in order: 

[Seek command issued ] 

Seek : 

<?xml version="1.0" encodings "UTF- 8 " standalone="yes " ?> 

< PLAYBACK EVENT version^ 7 1 . 0 7/ > 

<STATE ' value " = ^ Buffering 77 / > 

<PROGRESS value=" 0-100" ' units^ 7 percentage 77 /> 
</ PLAYBACK EVENT > 

<?xml version^'LCT 1 encoding="UTF-8" standalone="yes " ?> 
< PLAYBACK EVENT version^ 7 1 . 0" > 

< STATE valu e = J 7 PI ajvi n£ 7 /> 

</ PLAYBACK EVENT> 

For a standard pause of a live stream scenario of an mp3 format file, following are the 
events generated by the AudioStreamSource protocol, in order: 

[Pause command issued ] 

<?xml version="l. 0" encoding- "UTF- 8 " standalone="yes " ?> 
<PLAYBACK^Went ~ version^ 7 '! 7rr> ~ ■ 

<STATE " value = ""Paused 77 /> 
</ PLAYBACK EVENT> 

[Resume command issued ] 

Resume live stream: 

5 ?xml version=" 1.0" encodings "UTF-8 M _ s tandal one="yes " ?> 

< PLAY BACK EVENT version^ 77 l'To 77 > ~ * ' 

< STATE value = ^Buffering 77 / > 

^PROGRESS varue^ 7 0'lQ0 /7 units =^ percentage 77 /> 

</ PLAYBACK EVENT > 

<?xml version="l . 0" encoding="UTF-8 " standalo ne^' yes" ?> 

< PLAY BACK EVENT ve7siorP 7 Y'r6 77 "> " "~ " 

< STATE ~alue'""= "^Tlaying 77 /> 
</ PLAYBACK EVENT > 

For a standard stop-play scenario of an mp3 format file, following are the events 
generated by the AudioStreamSource protocol, in order: 

[Stop command issued] 

<?xml version="l . 0" encoding="UTF-8" standalone="yes " ?> 
< PLAYBACK EVENT version^ 1 . 0" > ~ 
< STATE value = " Stopped 77 /> 

[Play command issued ] 

Net congestion: 

5Jxml version="l . 0" encodings "UTF- 8 " standalone="yes " ?> 

< PLAYBACK EVENT verlio^tTF^ 

<STATE value = " Buf f erino" /> 



34 



<PROGRESS value=" 0-100" unit s^ 7 percentage^ /> 

</ PLAYBACK EVENT> 

<?xml version="l.Q" encoding="UTF-8" standalone="yes" ?> 
< PLAYBACK EVENT version^" 1 . 0" > 

< STATE value = // Playinq // /> 

</ PLAYBACK EVENT > 
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